REMARKS 



Applicant is in receipt of the Office Action mailed June 8, 2004. 

Rejections Under Sections 102 and 103 

Claims 1-3 and 7-16 were rejected under 35 U.S.C. 102(b) as being anticipated by 
Cosman et al. (US 5,943,060), hereafter referred to as Cosman. 

Claim 4 was rejected under 35 U.S.C. 103(a) as being unpatentable over Cosman 
et al. (US 5,943,060). 

Claims 5 and 6 were rejected under 35 U.S.C. 103(a) as being unpatentable over 
Cosman et al. (US 5,943,060) as applied to claim 1 above, and further in view of Snyder 
et al. (US 6,326,964), hereafter referred to as Snyder. 

Applicant respectfully traverses these rejections based on the following reasoning. 

Independent claims 1, 9, and 16 have been amended to more clearly state the 
limitation of the term samples. Claim 1 (amended) recites: 

"A method for generating pixels for a display device, the method comprising: 
rendering a plurality of samples from vertex data, wherein each sample is 

rendered for a specific point in screen space; 
storing the plurality of samples in a memory; 

storing a first portion of samples in a cache memory , wherein the first portion of 
samples is selected from the plurality of samples and corresponds to pixels 
in at least two neighboring scan lines; 

filtering a first subset of the first portion of samples to generate a first pixel in a 
first scan line ; and 

filtering a second subset of the first portion of samples to generate a second pixel 
in a second scan line , wherein the second scan line neighbors the first scan 
line." 
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Applicant's specification defines the process of rendering samples on page 25, lines 6-15: 
"Once the sample positions have been read from sample position memory 
354, draw process 352 selects the samples that fall within the polygon currently 
being rendered. This is illustrated in Figure 7. Draw process 352 then may 
calculate depth (z), color information, and perhaps other sample attributes (which 
may include alpha and/or a depth of field parameter) for each of these samples 
and store the data into sample buffer 22A. In one embodiment, sample buffer 
22A may only single-buffer z values (and perhaps alpha values) while double- 
buffering other sample components such as color. Graphics system 112 may 
optionally use double-buffering for all samples (although not all components of 
samples may be double-buffered, i.e., the samples may have some components 
that are not double-buffered)." 

Applicant's specification also defines the term sample on page 3, lines 14-22: 

"As used herein, the term "sample" refers to calculated information that 
indicates the color of the sample and possibly other information, such as depth 
(z), transparency, etc., of a particular point on an object or image . For 
example, a sample may comprise the following component values: a red value, a 
green value, a blue value, a z value, and an alpha value (e.g., representing the 
transparency of the sample). A sample may also comprise other information, e.g., 
a z-depth value, a blur value, an intensity value, brighter-than-bright information, 
and an indicator that the sample consists partially or completely of control 
information rather than color information (i.e., "sample control information")." 

Cosman neither teaches nor suggests 1) rendering a plurality of samples from 
vertex data, wherein each sample is rendered for a specific point in screen space and 
storing the plurality of samples in a memory, such as sample buffer 22A cited above, 2) 
storing a first portion of samples in a cache memory, or 3) the first portion of samples is 
selected from the plurality of [rendered] samples and corresponds to pixels in at least two 
neighboring scan lines. 
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Cosman does teach storing data describing one or more polygons for each pixel 
location on a per pixel basis and a mask for each polygon indicating each specific sub- 
pixel location that lies within the polygon in a frame buffer. However, sample data 
rendered for a specific sub-pixel location is not stored in the frame buffer . In addition, 
polygon data corresponds to a region or area of an object or image , not a specific point on 
an object or image as specified in Applicants claims. 

Cosman also teaches reading the polygon data stored for a given pixel that include 
a given sub-pixel location (the "heap"), but this information does not include the data 
defined above as "rendered samples". Instead, Cosman teaches using the polygon data 
read from the frame buffer to render sub-pixel values. The sub-pixel values rendered for 
each polygon are then combined or blended to generate pixel values without storing the 
individual sub-pixel values. 

Cosman teaches a system and method for reducing the size of a frame buffer 
memory by storing polygon data on a per pixel basis , rather than storing sub-pixel data. 
As disclosed in column 1, line 67 and column 2, lines 1-13 and 15-17, Cosman actually 
teaches away from storing sample values for each sub-pixel location : 

"For example, a graphics system that uses 16 sub-pixels per pixel and has 
a display with a 1024-by-1024 array of pixels would use over 16 million frame 
buffer locations for the sub-pixel data. Due to the relatively high cost of frame 
buffer memory, a need exists for a computer graphics display system that 
produces anti-aliased images, but uses less frame buffer memory . 

The present invention provides a novel memory allocation scheme and a 
novel sub-pixel sampling technique to reduce memory requirements and provide 
high quality anti-aliased images. The memory allocation scheme involves storing 
pixel data on a per-polygon, per-pixel basis rather than storing data for each sub- 
pixel as discussed above." 

"Pixel data is stored on a per-polygon, per-pixel basis in the frame buffer 
by separately storing each polygon that influences a pixel in memory locations 
allocated for that pixel ." 
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Applicant further submits that Cosman does not teach or suggest "reading a first 
portion of [rendered] samples from the memory, wherein the first portion of samples 
corresponds to pixels in at least two neighboring scan lines ". Cosman does not teach or 
suggest reading and processing polygon data for pixels in more than one scan line, nor 
even for more than one pixel at a time. In fact, the term "scan line" does not occur in 
Cosman. 

Cosman further does not teach using subsets of samples stored in a sample cache 
to perform: 

"filtering a first subset of the first portion of samples to generate a first pixel in a 
first scan line; and 

filtering a second subset of the first portion of samples to generate a second pixel 
in a second scan line, wherein the second scan line neighbors the first scan 
line." 

Therefore, amended claim 1 and its dependents are patentably distinguished over 
Cosman, for at least the reasons stated above. Amended claims 9 and 16 and new claim 
17 recite features similar to those recited in claim 1, and thus, claims 9 and its dependents 
and claims 16 and 17 are patentably distinguished over Cosman and Synder based on 
reasoning similar to that given above in support of claim 1. 
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CONCLUSION 



Applicant submits the application is in condition for allowance, and an early 
notice to that effect is requested. 

If any extensions of time (under 37 C.F.R. § 1.136) are necessary to prevent the 
above referenced application(s) from becoming abandoned, Applicant(s) hereby petition 
for such extensions. If any fees are due, the Commissioner is authorized to charge said 
fees to Meyertons, Hood, Kivlin, Kowert & Goetzel PC Deposit Account No. 50- 
1505/5181-85000/JCH. 

Also enclosed herewith are the following items: 
E*3 Return Receipt Postcard 
I I Request for Approval of Drawing Changes 
^ Notice of Change of Address 
l~l Check in the amount of $ for fees ( ). 
□ Other: 



Meyertons, Hood, Kivlin, Kowert & Goetzel PC 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8800 

Date: l>/?/\6^ JCH(iwc) 



Respectfully submitted, 




Jeffrey C. Hood 
Reg. No. 35,198 

ATTORNEY FOR APPLICANT(S) 
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